In certain storage area network (SAN) usage scenarios, such as those encountered by storage service providers (SSPs), there are multiple customers attempting to share common SAN resources. In such cases, there is a need to ensure that customers can only see and access the storage resources they have been allocated and prevent them from accessing storage of other customers. For example, if a customer stores their critical business data with a SSP, then they generally do not want other customers of the SSP reading their data or even being aware that they have information stored with the SSP. Thus, there is a need to secure the storage device resources so that only specified users or equipment connected to the SAN can access or be aware of those resources.
Further problems arise in some storage devices that can be subdivided into multiple separate resources. For example, a disk array can have multiple redundant arrays of independent disks (RAID) or partitions defined where each RAID set appears as a different fibre channel (FC) logical unit number (LUN). Each one of these FC LUNs can be dedicated to a different server. Therefore, it may not be possible to secure the resources of a SAN whole-device by whole-device. Instead, the SAN resources may need to be secured at the LUN level.
Existing fibre channel (FC) disk array firmware may be used to provide security in an FC redundant array of independent disks (RAID), since the disk array firmware has direct control over the array's ports connected to the SAN. Every host and device connection into the SAN generally has a unique FC-based world-wide-name (WWN), which can be used by an FC-based RAID to uniquely identify a device or host connection. Therefore, the FC-disk array firmware may be configured so that when a host attempts to send a small computer systems interface (SCSI) command to a FC-logical unit number (LUN) inside the RAID, the firmware will check the originating WWN from the server that sent the command against a list of authorized WWNs. If the WWN is on the list of authorized WWNs for that RAID FC-LUN, the SCSI command may be processed, if the WWN is not on the list of authorized WWNs for the RAID FC-LUN the command will be rejected. The list of authorized WWN's for each RAID FC-LUN may be configured via the existing management software for the RAID.
However, if an existing SCSI device such as a data tape library is connected to a FC-based SAN via a FC-to-SCSI bridge, it is not possible with existing security measures to secure these devices so that only certain hosts can see and access them. For example, if a tape library is connected to a SAN via a FC-to-SCSI bridge, then it is visible to and accessible by every server connected to that SAN. This is unacceptable from a data security standpoint for a SAN that provides storage resources to different customers.
Existing FC switches are capable of configuring security “zones” that define what WWNs or FC ports of servers can recognize listed WWN's or FC ports of devices. Such FC port and WWN security does not extend to FC addresses or FC device LUNs. Therefore, it is only possible to secure at the FC port level using existing FC switches on switch zoning.
Even were FC switches developed that have the capability of defining security zones down to the device LUN level, for SCSI tape libraries attached behind FC bridges, it still would be impractical for a user to define security zones. The tape library may have multiple FC bridges, with each bridge connected to a subset of the library tape drives. Additionally, the tape library may be logically partitioned, and such partitions may extend across multiple FC bridges. For example, a tape library partition may use three tape drives connected to two different FC bridges. It would be impractical for a user to correctly identify which FC ports and LUNs are associated together in the same security zone for an existing switch with any certainty. Understandably, mistakes may easily be made in such a manual process. Furthermore, to use existing switch zoning with a partitioned SCSI-based tape library the library controller should be on a separate bridge from any drives. This would require existing libraries to support two bridges per level, at least on one level, which existing libraries cannot do. Another problem is that switch zoning must be carried out per-bridge, so there would be a two drive per partition restriction/requirement for partitioned SCSI tape libraries connected to a SAN using existing FC-to-SCSI bridges.